Why is short project lifetime and other situation-specific reasons used to excuse crappy code? [clos
Posted
by sharptooth
on Stack Overflow
See other posts from Stack Overflow
or by sharptooth
Published on 2009-12-10T09:27:05Z
Indexed on
2010/04/25
5:33 UTC
Read the original article
Hit count: 226
best-practices
|human-factors
Every now and then (including on SO) people say things implying that "if the project is short lived you can leave obvious defects there" or "that memory leak only accounts for 100 bytes per whole program lifetime and could be left".
Now in my practice I always reuse company-owned code to the greatest extent I can. Like if I need something and I can find it in the company codebase I take it from there and reuse or adapt. This means that any crappy code will be reused as well and I might notice or not notice defects therein. So the defect in some "test we only need for a month" can slip into a proram we ship to customers. And a leak that "only accounted for 100 bytes per lifetime" now could account for 100 bytes 10 times per second in a server application intended to run for months.
That's why I don't understand why excuses like that are offered. Is our compamy the only one having a source control? Or are we the only company that requires writing human-readable code?
Could anyone shed a light on why people seriously offer such excuses?
© Stack Overflow or respective owner